[WIP] Initial multiple queues support by mikooomich · Pull Request #865 · FoedusProgramme/Gramophone

mikooomich · 2026-03-15T03:39:14Z

Adds "basic" support for multiple queues. Other needed features (ex. lastplayedmanger, queue menu) will be added later, or much later in terms of nice to haves (ex. multiselect, search, etc).

To test: Enable in Flags.kt, then enable settings toggle

nift4 · 2026-03-15T12:30:48Z

+            customExtras.putInt("index", index)
+        }, Bundle.EMPTY
+    ).get().extras.run {
+        if (containsKey("allQueues")) {


why bother with containsKey if you throw anyway, you can just let the !! do its job

nift4 · 2026-03-15T12:31:25Z

+    /**
+     * Deletes a queue.
+     *
+     * When deleting the active queue,


nift4 · 2026-03-15T12:31:50Z

+        if (index == masterQueues.lastIndex) {
+            masterQueues.removeAt(index)
+            if (index <= 0) {
+                player.pauseAllPlayersAndStopSelf() // TODO: correct way to stop playback


just removeMediaItems()

nift4 · 2026-03-15T12:33:07Z

    val endedWorkaroundPlayer
        get() = mediaSession?.player as EndedWorkaroundPlayer?
    private var controller: MediaBrowser? = null
+    val qb: QueueBoard = QueueBoard(this)


maybe should be inited in onCreate

nift4 · 2026-03-15T12:35:03Z

+    }
+
+// TODO: shuffle and repeat mode
+fun MediaController.playQueue(


you are doing this at the wrong level, Android AUto for example will just not call your SERVICE_QB_ENQUEUE, it will keep doing setMediaItems(). Instead a player wrapper should give old queue to queueboard before executing setMediaItems()

nift4 · 2026-03-15T12:35:32Z

+    /**
+     * Retrieve a song given a song ID. Returns null if no song is found
+     */
+    fun findSong(mediaId: String): MediaItem? {


For future uses. Should i remove it for the time being?

having smth for future use is ok if you know for what use, but atleast for me its not really clear what its useful for

nift4 · 2026-03-15T12:37:52Z

+
+                                val current = (instance?.currentMediaItemIndex ?: 0)
+                                if (current > playlistAdapter.playlist.second.size) {
+                                    // hax to workaround ui loading itself 4 times


nift4 · 2026-03-15T12:38:16Z

-                    controller?.setMediaItems(albums.shuffled().flatMap { it.songList })
-                    controller?.prepare()
-                    controller?.play()
+                    controller?.playQueue(


cf, this ui code shouldnt be changed. isOriginal is always true after setMediaItems(), it should only be considered changed after add/remove/move(/replace if id changed)

nift4 · 2026-03-15T12:42:24Z

+
+            if (startIndex == 0) {
+                val playerItemCount = plr.mediaItemCount
+                // player.player.replaceMediaItems seems to stop playback so we


replaceMediaItems probably does but replaceMediaItem without s does not, update current song with repalceMediaItem too

The currently playing media item can be at any index, and it needs to become the first index.. I'm not sure how replaceMediaItem would work better than what I current have.

I mean in addition to what you have, as replaceMediaItem updates metadata without interruptting playback

nift4 · 2026-03-15T12:42:46Z

+            return null
+        }
+
+        // I have no idea why this value gets reset to 0 by the end... but ig this works


nift4 · 2026-03-15T12:48:34Z

    <string name="actions_query_shuffle_specific">shuffle $item_name</string>
    <string name="please_allow_to_delete">Press allow to delete files</string>
    <string name="choose_sd">Choose %s</string>
+    <string name="settings_mq_preview">Enable multiple queues preview</string>


try to avoid mentioning preview, instead use strings that can be reused once feature is stable, to avoid double work for translators

* And so it begins: My attempt to implement one of OuterTune's most cursed features (code wise), but without programming crimes.

mq: wip queue loading ui mg: Guard behind flag mq: Queue expiry * LocalDateTime methods shouldn't need sdk 26. Figure it out later

* Changed some nonsense with loading LastPlayedManager queue * Fix some mq loading issues * Hijjack setMediaItems() instead of explicit playQueue(), * wip multiqueue shuffle (ui issues remain)

nift4 · 2026-04-25T20:00:27Z

+            startPositionMs = startPositionMs
+        )
+        queueBoard.commitQueue(mq)
+        return Futures.immediateVoidFuture()


why does this not call super?

commitQueue calls setCurrQueue, which then calls realSetMediaItems, so calling handleSetMediaItems setmediatems just leads to a duplicate call

I thought we already etablished that queueboard should only own inactive queues and the title of the active queue. that is, in setMediaItems it should copy the old queue into quereboard, not the new one. because if you want to do it this way then you also need to override at least handleAddMediaItems, handleMoveMediaItems, handleReplaceMediaItems, handleRemoveMediaItems, handleSeek which is stupid amount of effort, while if qb doesn't own current queue 1. nothing related to resumption etc needs to change 2. you avoid all of that spagetthi.

mikooomich · 2026-04-25T20:01:58Z

Hello. It has been... a while. I don't remember if I made all the requested changes, so if i missed anything plz let me know.

Known issues I will take care of... soon

queue title
wonky queue list close animation
play buttons from artists/albums etc page do not queue properly

Please help me figure out why the song recycler can scroll down but not up. Please please please please

nift4

Sorry don't have time for nested scroll debugging for at least 2 weeks, all I can give you rn is this quick review pass

nift4 · 2026-04-25T20:14:16Z

+            startPositionMs = startPositionMs
+        )
+        queueBoard.commitQueue(mq)
+        return Futures.immediateVoidFuture()


I thought we already etablished that queueboard should only own inactive queues and the title of the active queue. that is, in setMediaItems it should copy the old queue into quereboard, not the new one. because if you want to do it this way then you also need to override at least handleAddMediaItems, handleMoveMediaItems, handleReplaceMediaItems, handleRemoveMediaItems, handleSeek which is stupid amount of effort, while if qb doesn't own current queue 1. nothing related to resumption etc needs to change 2. you avoid all of that spagetthi.

nift4 · 2026-04-25T20:14:37Z

+    mediaItemIndex: Int,
+    isOriginal: Boolean
+) {
+    sendCustomCommand(


commented out much?

qb doesn't own the current queue. Yes, a full queue was added into qb via addqueue, but all that data (with the exception of the title) remains untouched and isnt actually used anywhere. All the old data is overwritten anyways with the latest from the player when setmediaitems is called again, so there is no spaghetti required.

I see how that commitQueue nonsense is redundant, so I'll change that. I'll null out the info in addQueue to prevent that info from creeping in in the future, and also call super.

Now (fe511a1) it works like this for when setmediaitems is called: handleSetMediaItems -> addqueue adds skeleton queue to qb, -> commitqueue facilitates the active/inactive swap within qb (without its own setmediaitems) -> super.handleSetMediaItems

And then for user initiated queue swaps: commitqueue facilitates the active/inactive swap within qb (with realSetMediaItems) -> super.handleSetMediaItems. You cant call setmediaitems again

nift4 · 2026-04-25T20:15:16Z

                    try {
-                        mediaSession?.player?.setMediaItems(
-                            items.mediaItems, items.startIndex, items.startPositionMs
+                        val mq = endedWorkaroundPlayer?.queueBoard?.addQueue(


see above, I think this part shouldnt need to change at all and qb should only manage inactive queue

nift4 · 2026-04-25T20:15:48Z

+                    }
+                }
+
+                SERVICE_QB_GET_QUEUE -> {


what is get for? can't we just have user call LOAD and then read it? or is there some UI where content of inactive is needed?

GET returns the queue with shuffle indexes for ui purposes, while LOAD is intended to facilitate the loading of the queue into the player. I don't believe these should be the same command.

nift4 · 2026-04-25T20:15:54Z

+                }
+
+                /*
+                SERVICE_QB_ENQUEUE -> {


commented out much?

nift4 · 2026-04-25T20:16:03Z

                        throw IllegalStateException("shuffleFactory was found orphaned")
                    if (isForPlayback && items.mediaItems.isNotEmpty()) {
-                        endedWorkaroundPlayer?.nextShuffleOrder = factory.toFactory()
+//                        endedWorkaroundPlayer?.nextShuffleOrder = factory.toFactory()


nift4 · 2026-04-25T20:16:19Z

+
+            plr.exoPlayer.setShuffleOrder(seed.toFactory()(mq.startIndex, mq.getSize(), plr))
+        } else {
+            Log.d(TAG, "Seamless is not supported. Loading songs in directly")


Remove logs btw

I'd prefer not. I mean, I'm willing to guard it behind a flag, but I wish to keep some debug logs around

nift4 · 2026-04-25T20:17:04Z

+            Log.d(TAG, "Seamless is not supported. Loading songs in directly")
+
+            if (plr.shuffleModeEnabled && mq.shuffleOrder == null)
+                Log.w(TAG, "Shuffle mode is enabled but no shuffle order is provided")


what about not storing that boolean and just making null mean shuffle is off? avoids inconsistency altogether. (shuffle order doesn't need to be stored if shuffle is off because enabling will reshuffle anyway)

setmediaitems stuff let setmediaitems handle lastplayedmanager

nift4 requested changes Mar 15, 2026

View reviewed changes

nift4 reviewed Mar 15, 2026

View reviewed changes

mikooomich force-pushed the multiqueue branch 2 times, most recently from 02e20d1 to 4304106 Compare April 8, 2026 14:46

mikooomich added 12 commits April 25, 2026 11:55

Bump agp, gradle

471afcd

mq: Introduce QueueBoard

4f39f96

* And so it begins: My attempt to implement one of OuterTune's most cursed features (code wise), but without programming crimes.

mq: Hijack setMediaItems

60e3b6f

mq: Initial multi queue ui

3ed4ed8

mq: wip queue loading ui mg: Guard behind flag mq: Queue expiry * LocalDateTime methods shouldn't need sdk 26. Figure it out later

mq: Correctly guard behind flag

73bfe3f

mq: Address review comments

048130e

mq: Use epoch millis instead of LocalDateTime

8b2ff7f

mq: wip

d917eee

* Changed some nonsense with loading LastPlayedManager queue * Fix some mq loading issues * Hijjack setMediaItems() instead of explicit playQueue(), * wip multiqueue shuffle (ui issues remain)

mq: Better handling for timer

c6ae8cb

mq: Add queue player controls

33caec9

DNM: Enable mq preview by default

9e9001a

DNM: Nick i hate you

aa7d9a0

mikooomich force-pushed the multiqueue branch from 4304106 to 33caec9 Compare April 25, 2026 19:37

nift4 reviewed Apr 25, 2026

View reviewed changes

nift4 requested changes Apr 25, 2026

View reviewed changes

wip

fe511a1

setmediaitems stuff let setmediaitems handle lastplayedmanager

Uh oh!

Conversation

mikooomich commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikooomich commented Apr 25, 2026

Uh oh!

nift4 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mikooomich commented Mar 15, 2026 •

edited

Loading